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APPEAL BRIEF 

Sir: 

This Appeal Brief is submitted in support of the Notice of Appeal filed on July 25, 

2011. 

I. REAL PARTY IN INTEREST 

Oracle International Corporation is the real party in interest. 

II. RELATED APPEALS AND INTERFERENCES 

A Notice of Appeal was filed on August 1 1, 201 1 for related U.S. Patent Application 
Serial Number 09/968,067. The Appeal Brief is due by October 1 1, 201 1 for this related 
application. Two prior Notices of Appeal were filed during prosecution of the related 
application. On August 4, 2005, the Appellant filed a first Notice of Appeal, and prosecution 
was re-opened by the examiner on January 3, 2006. On October 31, 2007, the Appellant 
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filed a second Notice of Appeal, and prosecution was re-opened by a pre-appeal brief panel 
on November 8, 2007. 

There are no other prior or pending appeals, judicial proceedings or interferences 
known to the Appellant which may be related to, directly affect or be directly affected by or 
have a bearing on the Board's decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 100-131 have been finally rejected and are the only subjects of this appeal. 

IV. STATUS OF AMENDMENTS 

The claims were not amended after the Final Office Action. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present application contains four independent claims: Claims 100, 108, 116, and 
124. Claims 100, 108, 116, and 124 are summarized below and annotated to cross-reference 
features of those claims to specific examples of those features disclosed in the specification. 
However, the annotations are not intended to limit the scope of the recited features to those 
specific examples to which the annotations refer. 

Claim 100 recites (with added reference annotations in parenthesis) a method comprising: A 
computer implemented method comprising: 

a source ETL application (paragraph [0043]) receiving, from a user, input that selects 
one or more database objects to be transported from a source database to a 
target database (paragraph [0021]); 

wherein said source database includes source database metadata that describes a 
structure of database objects of said source database (paragraph [0041]); 
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wherein said source database metadata identifies a set of tablespaces (paragraph 

[ 0040] and [ 0041 ] ) that store data for the one or more database objects to be 
transported (paragraph [0057]), and said set of tablespaces is in a format that 
is understandable by the target database (paragraph [0054]); 

wherein said source ETL application includes source ETL metadata (paragraph 
[0052]), separate from said source database metadata, that describes a 
structure of said database objects of said source database (paragraph [0032]); 
said source ETL application causing generation of a module comprising 
metadata that describes a structure of said one or more database objects of said 
source database (paragraph [0061]); 

a target ETL application reading said module (paragraphs [0049-0052] and Fig. 2); 

wherein said target database includes target database metadata that describes a 

structure of database objects of said target database (paragraph [0056] and 
[0041]); 

wherein said target ETL application includes target ETL metadata, separate from said 
target database metadata, that describes a structure of said database objects of 
said target database (paragraphs [0056], [0052] and [0032]); 
wherein reading said module causes said target ETL application to perform: 

modifying said target ETL metadata based on said source ETL metadata read 
from said module (paragraph [0056]) to describe a structure of said 
one or more database objects of said target database (paragraph 
[0056] and [0032]); and 
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modifying said target database metadata based on said metadata read from 

said module (paragraph [0056]) to describe a structure of said one or 
more database objects of said source database (paragraph [0056] and 
[0041]); 

a target database system incorporating a copy of said set of tablespaces that 
store said data for at least one of said one or more database objects 
(paragraph [0057] and [0040]), wherein incorporating said copy of 
said set of tablespaces includes modifying the target database metadata 
to define said copy of said set of tablespaces as a set of tablespaces that 
are used to store said data for at least one of said one or more database 
objects (paragraph [0057]). 

Claim 108 recites (with added reference annotations in parenthesis) A computer 
implemented method comprising: 

a source external application (paragraph [0043]) receiving, from a user, input that 
selects one or more database objects, wherein said one or more database 
objects include an internal database object to be transported from a source 
database to a target database and an external database object to be transported 
to a target external application (paragraph [0021]); 

wherein said source database includes source database metadata that describes a 

structure of said internal database object of said source database (paragraph 
[0041]); 
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wherein said source database metadata identifies a set of tablespaces (paragraph 

[ 0040] and [ 0041 ] ) that store data for the one or more database objects to be 
transported (paragraph [0057]), and said set of tablespaces is in a format that 
is understandable by the target database (paragraph [0054]); 

wherein said source external application includes source external application metadata 
(paragraph [0052]), separate from said source database metadata, that 
describes said one or more database objects (paragraph [0032]); 

said source external application causing generation of a module comprising metadata 
that describes a structure of said one or more database objects (paragraph 
[0061]); 

a target external application reading said module (paragraphs [0049-0052] and Fig. 
2); 

wherein said target database includes target database metadata that describes a 

structure of said internal database object (paragraph 1 0056 / and 1004 1 J); 

wherein said target external application includes target external metadata, separate 
from said target database metadata, that describes said one or more database 
objects(paragraphs [0056], [0052] and [0032]); and 

wherein said reading said module causes said target external application to perform 
loading said one or more database objects within said target database and said 
target external application (paragraph [0056], [0041] and [0032]), wherein 
loading includes: 

modifying said target external metadata to describe said one or more 
database objects (paragraph [0056] and [0032]); and 



OID 2003-177-01 



5 



Ser. No.: 10/783,779 Docket No. 50277-2334 

modifying said target database metadata to define a copy of said set of 
tablespaces as a set of tablespaces that are used to store said 
data for at least one of said one or more database 
objects(paragraph [0057]). 

Claim 116 recites (with added reference annotations in parenthesis) A computer-readable 
volatile or non- volatile storage device storing one or more sequences of instructions 
which, when executed by one or more processors, causes the one or more processors 
to perform: 

a source ETL application (paragraph 10043 1) receiving, from a user, input that selects 
one or more database objects to be transported from a source database to a 
target database (paragraph [0021]); 

wherein said source database includes source database metadata that describes a 
structure of database objects of said source database (paragraph [0041]); 

wherein said source database metadata identifies a set of tablespaces (paragraph 

[ 0040] and [ 0041 ] ) that store data for the one or more database objects to be 
transported (paragraph [0057]), and said set of tablespaces is in a format that 
is understandable by the target database (paragraph 100541); 

wherein said source ETL application includes source ETL metadata (paragraph 
[0052]), separate from said source database metadata, that describes a 
structure of said database objects of said source database (paragraph [0032]); 
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said source ETL application causing generation of a module comprising 

metadata that describes a structure of said one or more database objects of said 

source database (paragraph [0061]); 
a target ETL application reading said module (paragraphs [0049-0052] and Fig. 2); 
wherein said target database includes target database metadata that describes a 

structure of database objects of said target database (paragraph [0056] and 

[0041]); 

wherein said target ETL application includes target ETL metadata, separate from said 
target database metadata, that describes a structure of said database objects of 
said target database (paragraphs [0056], [0052] and [0032]); 
wherein reading said module causes said target ETL application to perform: 

modifying said target ETL metadata based on said source ETL metadata read 
from said module (paragraph [0056]) to describe a structure of said 
one or more database objects of said target database (paragraph 
[0056] and [0032]); and 
modifying said target database metadata based on said metadata read from 

said module (paragraph [0056]) to describe a structure of said one or 
more database objects of said source database (paragraph [0056] and 
[0041 J); 

a target database system incorporating a copy of said set of tablespaces that 
store said data for at least one of said one or more database objects 
(paragraph [0057] and [0040]), wherein incorporating said copy of 
said set of tablespaces includes modifying the target database metadata 
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to define said copy of said set of tablespaces as a set of tablespaces that 
are used to store said data for at least one of said one or more database 
objects (paragraph [0057]). 

Claim 124 recites (with added reference annotations in parenthesis) A computer-readable 
volatile or non- volatile storage device storing one or more sequences of instructions 
which, when executed by one or more processors, causes the one or more processors 
to perform: 

a source external application (paragraph [00431) receiving, from a user, input that 
selects one or more database objects, wherein said one or more database 
objects include an internal database object to be transported from a source 
database to a target database and an external database object to be transported 
to a target external application (paragraph [0021]); 

wherein said source database includes source database metadata that describes a 

structure of said internal database object of said source database (paragraph 
[0041]); 

wherein said source database metadata identifies a set of tablespaces (paragraph 

[ 0040] and [ 0041 ] ) that store data for the one or more database objects to be 
transported (paragraph [0057]), and said set of tablespaces is in a format that 
is understandable by the target database (paragraph [0054]); 

wherein said source external application includes source external application metadata 
(paragraph [0052]), separate from said source database metadata, that 
describes said one or more database objects (paragraph [0032]); 
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said source external application causing generation of a module comprising metadata 
that describes a structure of said one or more database objects (paragraph 
[0061]); 

a target external application reading said module (paragraphs [0049-0052] and Fig. 

2); 

wherein said target database includes target database metadata that describes a 

structure of said internal database object (paragraph [0056] and [0041]); 

wherein said target external application includes target external metadata, separate 
from said target database metadata, that describes said one or more database 
objects(paragraphs [0056], [0052] and [0032]); and 

wherein said reading said module causes said target external application to perform 
loading said one or more database objects within said target database and said 
target external application (paragraph [0056], [0041] and [0032]), wherein 
loading includes: 

modifying said target external metadata to describe said one or more 
database objects (paragraph [0056] and [0032]); and 

modifying said target database metadata to define a copy of said set of 
tablespaces as a set of tablespaces that are used to store said 
data for at least one of said one or more database 
objects( paragraph [0057]). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 100, 108, 1 16, and 124 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

2. Claims 101, 109, 1 17, and 125 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

3. Claims 102, 1 10, 118, and 126 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

4. Claims 103, 111,1 19, and 127 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

5. Claims 104, 1 12, 120, and 128 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

6. Claims 105, 1 13, 121, and 129 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 

7. Claims 106, 1 14, 122, and 130 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 
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8. Claims 107, 1 15, 1 123, and 131 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable, allegedly, over U.S. Patent No. 7,139,779 ("Kornelsion") in view of U.S. 
Pub. No. 2004/0034615 Al ("Thompson"). 
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VII. ARGUMENTS 

A. The Features of Claims 100, 108, 116, and 124 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thompson 

The following is provided for understanding the claims. Various features of various 
claims are described for purposes of exposition, but not for the purpose of arguing any single 
claim that expresses or requires that feature. The limitations of any particular claim, and 
distinguishing features thereof, are explained later. 

The claimed ETL system is comprised of a source database, a source ETL 
application, a module, a target ETL application, and a target database. The source ETL 
application generates the module that comprises metadata that describes the structure of 
database objects to be transported from the source database to the target database. The 
metadata in the generated module is based on source database metadata. As a result of 
reading the module, the target ETL application: 

1 . modifies ETL application metadata 

2. modifies target database metadata 

3. incorporates into the target database a copy of the source database tablespaces that 
store the data to be transported. 

Kornelson describes a system for reading log files and loading the data into a 
database. Kornelson is directed to generating, from a dataflow diagram, an ETL application, 
metafile, and installation script for installing the generated application and metafile. The 
Examiner analogized Kornelson' s installation script to the claimed module because the 
Examiner interprets the installation script to modify the ETL application metadata. 

Even if it were reasonable to interpret Kornelson' s installation script as modifying 
ETL application metadata, Kornelson' s installation script is not generated by a source ETL 
and does not cause a target ETL application to perform the other functions described above 
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such as modifying target database metadata or incorporating tablespaces into the target 
database. Thus, the installation script cannot be considered equivalent to the claimed 
module. 

Kornelson's application, metafile, and installation script are generated prior to 
moving data from log files into the target database. Kornelson describes a single ETL 
application, not a source ETL application and a target ETL application. Even if Kornelson's 
application could be considered analogous to the claimed source ETL application, 
Kornelson's application does not cause a module to be generated, as claimed. 

In addition to these fundamental distinctions, there are several specific 
features of the claims that are not taught by Kornelson in combination with Thomson: 

1. Kornelson does not teach or suggest a source ETL application generating a module. 

2. Kornelson does not teach or suggest modifying target database metadata. 

3. Kornelson does not teach or suggest incorporating tablespaces; fact and dimension 
tables are not tablespaces. 

4. Kornelson does not mention any metadata that defines tablespaces. 
These distinctions are explained more fully below. 

1. Kornelson does not teach or suggest a source ETL application generating a 
module 

The Examiner relies on Kornelson at col. 8, lines 20-35 to allegedly teach a source 
ETL generating a module comprising metadata that describes a structure of one or more 
database objects of said source database. This is incorrect. In fact, it appears the "module" 
the Examiner relies upon appears to be generated by a development team and not a source 
ETL and installed directly onto Kornelson's database. 

The paragraph cited by the examiner involves the use of configuration files. The 
previously mentioned installation script of Kornelson, "when executed installs the 
application program and the configuration file onto a computer such that the installed 

OID 2003-177-01 13 



Ser. No.: 10/783,779 



Docket No. 50277-2334 



application program executes per the generated configuration file to implement the ETL 
system" (Kornelson, col. 10, lines 23-27). The configuration file is "automatically generated 
from the data flow diagram" (Kornelson, col. 10, lines 21-23). Wherein, the data flow 
diagram appears to be nothing more than a notation created by developers to describe the 
transformation steps (See Kornelson, Col. 8, lines 40-60). Specifically, Kornelson describes 
"gathering requirements from program management and/or customers about the input to the 
ETL system . . . designing a pipeline using the notation described herein to transform the 
input to the output . . . [and] reviewing the pipeline with program management and database 
designers" (Kornelson, Col. 7, line 63, through Col. 8, line 20). Even the summary states "the 
invention includes a set of tools, a process, and a notion for specifying an ETL system that 
enables the design of the ETL system in a relatively short amount of time (e.g., two weeks)" 
(Kornelson, Col. 3, lines 34-37). Thus, it appears Kornelson was focused on the creation of a 
development process to speed up the time it takes to implement and code an ETL system. 

Furthermore, the Examiner appears to equate the "internet servers" described in Col. 5, 
lines 45-60 with a source database and ETL application. Even if such an association were 
accurate, there is no indication that the internet servers ever even obtain, much less generate, 
the "module" as it is characterized by Examiner. In fact, in Kornelson the only apparent 
exchange between the internet servers and the database is that the "[s]ystem periodically 
provides a pre-processor component to each of the servers. Each server executes the 
preprocessor component to pre-process that server's data. Each server compresses the pre- 
processed log data and sends it to the collection computer" (Kornelson, Col. 6, lines 44-49). 
Even if we were to consider the log data as database objects, the system of Kornelson would 
already need to know the structure of how the data is stored at the internet server in order to 
tell the servers how to preprocess it. Also, there is no indication that the log contains 
anything other than compressed data such as "web logs, instant messaging logs, newsletter 
usage statistics ... and mobile usage statistics" (Kornelson Col. 6, lines 50-52). This provides 
further evidence that the Examiner's "module" is created and installed beforehand on the 
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target database and is not generated or sent by any source ETL application. Therefore, 
Kornelson does not teach or suggest a source ETL application generating a module 
comprising metadata that describes a structure of one or more database objects of said source 
database. 

2. Kornelson does not teach or suggest modifying target database metadata. 

The Examiner relies on Kornelson at col. 8, lines 20-35 to allegedly teach modifying 
said target database metadata based on said metadata read from said module to describe a 
structure of said one or more database objects of said source database. However, the claims 
recite that the modifying is performed by said target ETL application. The Examiner appears 
to equate Kornelson' s ETL toolset that is used to generate the ETL application with the ETL 
application itself. This is not correct. The ETL toolset creates the ETL application and the 
ETL application performs extraction, transformation, and loading of the data. Furthermore, 
neither the ETL toolset, nor the generated ETL application modifies target database 
metadata to describe a structure of database objects of said source database. 

Although Kornelson may place the log file data in fact and dimension tables that are 
merged with tables already in the target database, the table merge process does not modify 
the structure of the tables within the target database. Unlike the Examiner alleges, merging 
data does not inherently change the data's structure. 

Kornelson' s aggregation computer that prepares the source data for loading into the 
target database creates fact and dimension tables based on the target database structure that 
already exists. Thus, there is no need to modify target database metadata to describe the 
structure of database objects from the source database. 

3. Kornelson does not teach or suggest incorporating tablespaces; fact and 
dimension tables are not tablespaces. 
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The Office Action relies on the passage at Column 7, lines 5-35 of Kornelson to 
allegedly teach the feature of incorporating tablespaces. The cited passage describes the 
creation of fact files and dimension files that are constructed from data extracted from the log 
files. However, there is no teaching or suggestion in the cited passage or anywhere else in 
Kornelson of tablespaces, much less source metadata that identifies tablespaces. 

The claims recite tablespaces, and the Examiner alleges that Kornelson teaches 
tablespaces. That is factually incorrect. The Examiner does not provide any further 
explanation as to how and whether Kornelson or Thomson teach tablespaces, and thus, the 
above Examiner response is not responsive to Applicants' arguments. 

In addition, as noted above, the Examiner considers the source database to be the 
same as a log file. Thus, to consistently interpret the claim, the Examiner must also consider 
the source database metadata to be data about the log file. Information about the log file is 
not contained within the log file itself. There is no teaching or suggestion that the format of 
the logged data is self-describing. Thus, the metadata about the log file must be configured 
outside of the log file. There is also no teaching or suggestion that metadata about the log 
file identifies a tablespace, as claimed. Even if it were reasonable to consider a log file to be 
the same as a tablespace, the log file [tablespace] is not in a format that is understandable by 
the target database, as claimed. Kornelson' s system transforms the data read from the log 
file into database tables. The data read from the log file only becomes understandable to the 
target system after its format has been transformed. If the data in the log file [tablespace] 
were already understandable to the target database, there would be no need to perform a 
transformation on the data. 

The cited passage also describes the construction of fact tables and dimension tables 
in the target data warehouse database, but the fact tables and dimension tables neither 
identify nor comprise a set of tablespaces. Even if fact tables and dimension tables identified 
tablespaces, fact tables and dimension tables [source database metadata] do not contain data 
about the log file [source database]. Likewise, even if it were reasonable to consider a fact 
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table or dimension table to be the same as a tablespace, neither a fact nor a dimension table 
comprises data to be transported. Kornelson's fact and dimension table may be an 
intermediate representation of the data during transport, but they do not store database 
objects to be transported, as claimed. A person of ordinary skill in the art would have 
interpreted "data to be transported in an ETL system" to mean the source of the data to be 
moved from one database system to another. In Kornelson, the source data is the data from 
the log files, not the data in the fact or dimension tables. 

Thomson does not, nor is it alleged to, teach tablespaces. There is no mention of 
tablespaces in Thomson, nor is there any other equivalent structure in Thomson that teaches 
or suggests tablespaces. 

In response, the Examiner alleges that for obviousness the test is what combined 
teachings of references would have suggested to those of ordinary skill in the art.". 

However, to establish prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 
USPQ 580 (CCPA 1974). Obviousness under 35 U.S.C. § 103(a) is ultimately a legal 
question, based on underlying factual determinations. See Richardson-Vicks Inc. v. 
Upjohn Co., 122 FJd 1476, 1479 (Fed. Cir. 1997). The factual determinations underpinning 
the legal conclusion of obviousness include 1) the scope and content of the prior art, 2) the 
level of ordinary skill in the art, 3) the differences between the claimed invention and the 
prior art, and 4) evidence of secondary factors, also known as objective indicia of non- 
obviousness. Graham v. John Deere Co., 383 U.S. 1, 17-18 (1966). In the present matter, the 
Examiner has made clearly erroneous factual findings regarding the scope and content of the 
prior art, and in particular, what certain cited prior art references teach. Therefore, the 
Examiner's analysis and the obviousness rejection based thereon are invalid. 

4. Kornelson does not mention any metadata that defines tablespaces. 
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The Examiner relies on column 12, lines 1-15 to allegedly teach metadata that defines 
tablespaces. However, the cited passage is part of a general description of a computing 
environment in which Kornelson's approach may be used. There is no mention in the cited 
passage of target databases, tablespaces, target database metadata or any equivalent element 
thereof. 

The Examiner has alleged 

"In this case metadata is simply data about data and almost all of the data used in 
either reference would classify as metadata. Moreover the disclosure ofKornelson 
clearly indicate incorporating and storing multiple copies.... " 

Even if Kornelson and Thomson describe data that may be considered metadata, 
neither reference describes metadata that defines tablespaces used to store database objects in 
the database, as claimed. As explained above, neither Kornelson nor Thomson teaches or 
suggests tablespaces, and thus, neither reference teaches or suggests metadata that defines 
tablespaces to store database objects. The above quoted Examiner response alleges that 
Kornelson suggests incorporating and storing multiple copies of some unnamed item, but 
does not explain how incorporating and storing multiple copies of some unnamed item 
teaches target database metadata that defines tablespaces for storing database objects. 

Therefore, Applicant has identified several features of Claims 100, 108, and 116 124 
that are not taught or suggested by Kornelson and Thomson, alone or in combination. 

B. The Features of Claims 101, 109, 117, and 125 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 100, 108, 1 16 or 124, Claims 101, 
109, 1 17, and 125 inherit the features that are distinguished from Kornelson and Thomson 
above. 



OID 2003-177-01 



18 



Ser. No.: 10/783,779 



Docket No. 50277-2334 



Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 101, 109, 117, and 125 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 101, 109, 
117, and 125 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 101, 109, 117, and 125 
should be reversed. 

Additionally, the Examiner relies upon Thomson at paragraph [0066] to 
describe "in response to a failure occurring during the loading of said database objects within 
said target database, rolling back all changes made during the loading of the database objects 
to the target database". 

Thomson states that "the present invention supports context transfer between any 
combination of data sources and originating and target query tool or application by 
translating, or mapping, from data in an originating format (the "originating report"), to data 
in a target database presentation, or target format (the "target report")" (Thomson, Paragraph 
[0051]). Here, "Context" is defined as "a perspective or a set of dimensional criteria in a 
multi-dimensional "slice" or point in the data space of the database that a user is navigating" 
and the "context model" is described as "the format, or structure, of the query". (See 
Thomson, Paragraph [0038] and Paragraph [0061]). Therefore, Thomson is concerned with 
translating queries from one format to another. The end result being that "[t]he changes that 
have been applied have used the query specification of the target report tool, so the target 
report is in no way different than if the user had created the report using the user interface of 
the target client query tools" (Thomson, Paragraph [0066]). An example of a Thomson report 
can be found at Fig. 9. 

Therefore, Paragraph [0066] merely describes that the reports should seem the same 
whether the query was created by the target query tools or created by the originating query 
tools and translated by a server running a UDS bridge (See Fig. 1). Even if it were accurate to 
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consider the target report a collection of database objects, Thomson is silent regarding what 
to do with the report once it is received. The only passage that seems to describe what 
happens with the report states "UDS imposes no restrictions on what can be done in the 
originating report and does not restrict what can be done with the target report after 
completion of a drill-through transaction" (Thomson, Paragraph [0066]). Since the target 
report is almost certainly in a different format, even if the originating client were a database, 
it would not be able to load the target report. Most likely, the report is simply displayed for 
the benefit of the user such as in Fig. 9. Thus, since there is no loading, there are no loading 
failures necessitating rollback in Thomson. Therefore, since Kornelson was never cited as 
teaching rollbacks and Thomson does not teach or suggest rolling back all changes made 
during the loading of the database objects to the target database, the rejection of Claims 101, 

109, 117, and 125 should be reversed. 

C. The Features of Claims 102. 1 10. 118. and 126 Are Not Disclosed. Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 100, 108, 1 16 or 124, Claims 102, 

110, 118, and 126 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 102, 1 10, 118, and 126 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 102, 110, 
118, and 126 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 102, 110, 118, and 126 
should be reversed. 
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Additionally, the Examiner cites Thomson paragraphs [015 1]-[0153] as 
describing "wherein the selected one or more database objects to be transported from a 
source database to a target database includes a database object that has metadata stored 
outside of the source database". As mentioned previously, even if the report could be 
considered a collection of database objects, the selected objects in the originating report are 
not being transferred. Rather, they are being used to generate a query. Paragraphs [0151]- 
[0153] merely describe examples of Thomson's "Translation Model" for queries. Therefore, 
not only is there no evidence that those objects have metadata outside of what the Examiner 
considers the database, but the objects themselves are not even being transferred. As such, 
Thomson does not teach or suggest "wherein the selected one or more database objects to be 
transported from a source database to a target database includes a database object that has 
metadata stored outside the source database". 

D. The Features of Claims 103. 111.1 19. and 127 Are Not Disclosed. Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 100, 108, 116 or 124, Claims 103, 
111, 119, and 127 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 103, 111, 119, and 127 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 103, 110, 
1 19, and 127 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 103, 111, 119, and 127 
should be reversed. 
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Additionally, the Examiner relies on paragraph [0009] to describe "wherein 
generation of a module includes analyzing the source database metadata for dependencies". 
However, [0009] recites, "OLAP and Relational technologies are complimentary and there is 
a strong motivation to allow navigation back and forth ... a problem arises in 'mapping' user 
views of data in OLAP with items of data in a relational database ... the user may then 
request to view a list of promotional sales for individual products ... the OLAP interface will 
attempt to fulfill the user's request only to discover that it doesn't store data on individual 
products". OLAP being a database access method wherein "data in a relational type of 
database is pre-processed prior to the time a user performs OLAP accessing ... for example, 
... the administrator may direct the OLAP system to precompute tables, or other collections 
of data" (Thompson [0007]). Thus, "OLAP differs from the relational type of accessing 
because in OLAP the results of a query, or other user access action, do not always require 
computing presentations, or views, from 'raw' data items" (Thompson [0008]). 

In Thompson, OLAP appears to simply be a pre-computed presentation in order to 
save time and resources of the relational database. As such, it is difficult to discern what the 
examiner considers the "module" in the above passage. However, even assuming a module 
exists, OLAP would not be dependant upon the relational tables. If the opposite were the case 
and the OLAP were dependant upon the relational tables, access to OLAP would also require 
access to the relational tables, an expense which OLAP's very purpose seems to be to avoid. 
Furthermore, OLAP and the relational tables appear to be separate databases, and the 
originating database in this case seems to be, from the way the Examiner is interpreting the 
passage, the relational database. Nowhere in the cited passage does it describe analyzing the 
relational database's metadata for dependencies. Therefore, Thompson does not teach or 
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suggest "wherein generation of a module includes analyzing the source database metadata for 
dependencies". 

E. The Features of Claims 104, 112, 120, and 128 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 103, 111, 1 19 or 127, Claims 104, 
112, 120, and 128 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 104, 112, 120, and 128 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 104, 112, 
120, and 128 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 104, 1 12, 120, and 128 
should be reversed. 

Additionally, the Examiner cites paragraphs [0046] and [0107] in Thomson as 
disclosing "wherein analyzing the source database metadata for dependencies includes 
ensuring proper order of loading of the source database metadata into the target database". 
As mentioned above, Thomson does not teach or suggest loading database objects into a 
database or analyzing the source database metadata for dependencies. Furthermore, the 
paragraph cited by the examiner comes from the section entitled "context selection" and 
describes generating a query from user input and even for that completely different task, 
makes no mention of any particular ordering (See Thomson, Paragraph [0107). Therefore, 
Thomson does not teach or suggest "wherein analyzing the source database metadata for 



OID 2003-177-01 



23 



Ser. No.: 10/783,779 Docket No. 50277-2334 

dependencies includes ensuring proper order of loading of the source database metadata into 
the target database". 

F. The Features of Claims 105, 1 13, 121. and 129 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 100, 108, 1 16 or 124, Claims 105, 
113, 121, and 129 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 105, 113, 121, and 129 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 105, 113, 
121, and 129 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 105, 113, 121, and 129 
should be reversed. 

Additionally, the Examiner cites Thomson paragraph [0046] as describing "storing 
said module in one or more files in a source file system". As mentioned previously, it is 
unclear what the Examiner considers the "module" in Thomson. Paragraph [0046] is a just 
definition which states (quoted in full) "'Structure' refers to the framework in which data is 
stored in a database. In most cases, a database has a hierarchy of frameworks (e.g. 
server/database/cube/dimension/level) as data can be complex and large". Nowhere in this 
definition is described a module or saving a module in one or more files in a source data 
system. Therefore, Thomson does not teach or suggest "storing said module in one or more 
files in a source file system". 
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G. The Features of Claims 106, 114, 122, and 130 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thomson 

By virtue of their dependence from either Claim 105, 1 13, 121 or 129, Claims 106, 
1 14, 122, and 130 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 106, 114, 122, and 130 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 106, 1 14, 
122, and 130 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 106, 1 14, 122, and 130 
should be reversed. 

Additionally, the Examiner cites Kornelson Col. 7, lines 55-68 as describing "reading 
a specification containing information for how to move modules from said source file system 
to a target file system". As argued above, Kornelson appears to involve system 
administrators installing what the Examiner considers the "module" directly into the 
database. As such, it would have no need for a specification detailing how to move a module 
from one file system to another. Therefore, Kornelson does not teach or suggest "reading a 
specification containing information for how to move modules from said source file system 
to a target file system". 

H. The Features of Claims 107, 115, 123, and 131 Are Not Disclosed, Taught, or Suggested 
by Kornelson or Thomson 
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By virtue of their dependence from either Claim 100, 108, 1 16 or 124, Claims 107, 
1 15, 123, and 131 inherit the features that are distinguished from Kornelson and Thomson 
above. 

Since Kornelson and Thomson do not disclose, teach, or suggest the distinguished 
features that Claims 107, 115, 123, and 131 inherit, even a combination Kornelson and 
Thomson could not disclose, teach, or suggest these features. Therefore, Claims 107, 1 15, 
123, and 131 are patentable over Kornelson and Thomson, taken either individually or in 
combination, under 35 U.S.C. § 103(a). The rejection of Claims 107, 115, 123, and 131 
should be reversed. 

VIII. CONCLUSION AND PRAYER FOR RELIEF 

Based on the foregoing, it is respectfully submitted that the rejections of Claims 100- 

131 lack the requisite factual and legal bases. Appellants respectfully request that the 

Honorable Board reverse the rejections of Claims 100-131. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 

Dated: October 5, 2011 /JustinRBaratz#68076/ 

Justin R Baratz 
Reg. No. 68,076 

2055 Gateway Place, Suite 544 
San Jose, California 95110 
Telephone No.: (408) 414-1080 x222 
Facsimile No.: (408) 408-1076 
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CLAIMS APPENDIX 
100. A computer implemented method comprising: 

a source ETL application receiving, from a user, input that selects one or more 

database objects to be transported from a source database to a target database; 
wherein said source database includes source database metadata that describes a 

structure of database objects of said source database; 
wherein said source database metadata identifies a set of tablespaces that store data 

for the one or more database objects to be transported, and said set of 

tablespaces is in a format that is understandable by the target database; 
wherein said source ETL application includes source ETL metadata, separate from 

said source database metadata, that describes a structure of said database 

objects of said source database; 

said source ETL application causing generation of a module comprising 
metadata that describes a structure of said one or more database objects of said 
source database; 
a target ETL application reading said module; 

wherein said target database includes target database metadata that describes a 

structure of database objects of said target database; 
wherein said target ETL application includes target ETL metadata, separate from said 

target database metadata, that describes a structure of said database objects of 

said target database; 
wherein reading said module causes said target ETL application to perform: 
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modifying said target ETL metadata based on said source ETL metadata read 
from said module to describe a structure of said one or more database 
objects of said target database; and 

modifying said target database metadata based on said metadata read from 
said module to describe a structure of said one or more database 
objects of said source database; 

a target database system incorporating a copy of said set of tablespaces that 
store said data for at least one of said one or more database objects, 
wherein incorporating said copy of said set of tablespaces includes 
modifying the target database metadata to define said copy of said set 
of tablespaces as a set of tablespaces that are used to store said data for 
at least one of said one or more database objects. 



101. The method of Claim 100, further comprising: 

in response to a failure occurring during the loading of said database objects within 
said target database, rolling back all changes made during the loading of the 
database objects to the target database. 



102. The method of Claim 100, wherein the selected one or more database objects to be 

transported from a source database to a target database includes a database object that 
has metadata stored outside of the source database. 
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The method of Claim 100, wherein generation of a module includes analyzing the 
source database metadata for dependencies. 



104. The method of Claim 103, wherein analyzing the source database metadata for 
dependencies includes ensuring proper order of loading of the source database 
metadata into the target database. 

105. The method of Claim 100, further comprising: 

storing said module in one or more files in a source file system. 

106. The method of Claim 105, further comprising: 
said target ETL application performing: 

reading a specification containing information for how to move modules from 

said source file system to a target file system; 
wherein said information comprises a network protocol and the location in the 

source file system of said one or more files; and 
accessing said one or more files in a source file system based on said 

information. 

1 07 . The method of Claim 1 06, wherein the network protocol is one of FTP, HTTP, 
HTTPS, or rsync. 

108. A computer implemented method comprising: 
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a source external application receiving, from a user, input that selects one or more 
database objects, wherein said one or more database objects include an 
internal database object to be transported from a source database to a target 
database and an external database object to be transported to a target external 
application; 

wherein said source database includes source database metadata that describes a 
structure of said internal database object of said source database; 

wherein said source database metadata identifies a set of tablespaces that store data 
for the one or more database objects to be transported, and said set of 
tablespaces is in a format that is understandable by the target database; 

wherein said source external application includes source external application 

metadata, separate from said source database metadata, that describes said one 
or more database objects; 

said source external application causing generation of a module comprising metadata 
that describes a structure of said one or more database objects; 

a target external application reading said module; 

wherein said target database includes target database metadata that describes a 

structure of said internal database object; 
wherein said target external application includes target external metadata, separate 

from said target database metadata, that describes said one or more database 

objects; and 
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wherein said reading said module causes said target external application to perform 
loading said one or more database objects within said target database and said 
target external application, wherein loading includes: 

modifying said target external metadata to describe said one or more 

database objects; and 
modifying said target database metadata to define a copy of said set of 
tablespaces as a set of tablespaces that are used to store said 
data for at least one of said one or more database objects. 

109. The method of Claim 108. wherein generation of a module includes analyzing the 
source database metadata for dependencies. 

1 10. The method of Claim 109, wherein analyzing the source database metadata for 
dependencies includes ensuring proper order of loading of the source database 
metadata into the target database. 

111. The method of Claim 108, further comprising: 

storing said module in one or more files in a source file system. 

112. The method of Claim 111, further comprising: 
said target ETL application performing: 

reading a specification containing information for how to move modules from 
said source file system to a target file system; and 
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wherein said information comprises a network protocol and the location of 
said one or more files; and 
accessing said one or more files in a source file system based on said information. 

113. The method of Claim 112, wherein the network protocol is one of FTP, HTTP, 
HTTPS, or rsync. 

1 14. The method of Claim 108, further comprising: 

in response to a failure occurring during the loading of said database objects within 
said target database, rolling back all changes made during the loading of the 
database objects to the target database. 

115. The method of Claim 108, wherein said one or more database objects to be 
transported from a source database to a target database includes a database object that 
has metadata stored outside of the source database. 

116. A computer- readable volatile or non- volatile storage device storing one or more 
sequences of instructions which, when executed by one or more processors, causes the 
one or more processors to perform: 

a source ETL application receiving, from a user, input that selects one or more 

database objects to be transported from a source database to a target database; 

wherein said source database includes source database metadata that describes a 
structure of database objects of said source database; 
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wherein said source database metadata identifies a set of tablespaces that store data 
for the one or more database objects to be transported, and said set of 
tablespaces is in a format that is understandable by the target database; 

wherein said source ETL application includes source ETL metadata, separate from 
said source database metadata, that describes a structure of said database 
objects of said source database; 

said source ETL application causing generation of a module comprising 
metadata that describes the structure of said one or more database objects of 
said source database; 
a target ETL application reading said module; 

wherein said target database includes target database metadata that describes a 

structure of database objects of said target database; 
wherein said target ETL application includes target ETL metadata, separate from said 
target database metadata, that describes a structure of said database objects of 
said target database; 
wherein reading said module causes said target ETL application to perform: 

modifying said target ETL metadata based on said source ETL metadata read 
from said module to describe a structure of said one or more database 
objects of said target database; and 
modifying said target database metadata based on said metadata read from 
said module to describe the structure of said one or more database 
objects of said source database; 
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a target database system incorporating a copy of said set of tablespaces that 
store said data for at least one of said one or more database objects, 
wherein incorporating said copy of said set of tablespaces includes 
modifying the target database metadata to define said copy of said set 
of tablespaces as a set of tablespaces that are used to store said data for 
at least one of said one or more database objects. 



117. The computer-readable volatile or non-volatile storage device of Claim 116, 

further comprising instructions which, when executed by one or more processors, 
causes the one or more processors to perform: 

in response to a failure occurring during the loading of said database objects within 
said target database, rolling back all changes made during the loading of the 
database objects to the target database. 



118. The computer-readable volatile or non-volatile storage device of Claim 116, 

wherein the selected one or more database objects to be transported from a source 
database to a target database includes a database object that has metadata 
stored outside of the source database. 



119. The computer-readable volatile or non-volatile storage device of Claim 116, 

wherein generation of a module includes analyzing the source database metadata for 
dependencies. 
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120. The computer-readable volatile or non- volatile storage device of Claim 119, 

wherein analyzing the source database metadata for dependencies includes ensuring 
proper order of loading of the source database metadata into the target 
database. 



121. The computer-readable volatile or non-volatile storage device of Claim 116, 

further comprising instructions which, when executed by one or more processors, 
causes the one or more processors to perform: 
storing said module in one or more files in a source file system. 



122. The computer-readable volatile or non-volatile storage device of Claim 121, 

further comprising instructions which, when executed by one or more processors, 

causes the one or more processors to perform: 
said target ETL application reading a specification containing information for how to 
move modules from said source file system to a target file system; 
wherein said information comprises a network protocol and the location in the 
source file system of said one or more files; and 
said target ETL application accessing said one or more files in a source file system 
based on said information. 



123. The computer-readable volatile or non-volatile storage device of Claim 122, 
wherein the network protocol is one of FTP, HTTP, HTTPS, or rsync. 
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124. A computer-readable volatile or non-volatile storage device storing one or more 

sequences of instructions which, when executed by one or more processors, causes the 
one or more processors to perform: 

a source external application receiving, from a user, input that selects one or more 
database objects, wherein said one or more database objects include an 
internal database object to be transported from a source database to a target 
database and an external database object to be transported to a target external 
application; 

wherein said source database includes source database metadata that describes a 
structure of said internal database object of said source database; 

wherein said source database metadata identifies a set of tablespaces that store data 
for the one or more database objects to be transported, and said set of 
tablespaces is in a format that is understandable by the target database; 

wherein said source external application includes source external application 

metadata, separate from said source database metadata, that describes said one 
or more database objects; 

said source external application causing generation of a module comprising metadata 
that describes a structure of said one or more database objects; 

a target external application reading said module; 

wherein said target database includes target database metadata that describes a 
structure of said internal database object; 
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wherein said target external application includes target external metadata, separate 
from said target database metadata, that describes said one or more database 
objects; and 

wherein said reading said module causes said target external application to perform 
loading said one or more database objects within said target database and said 
target external application, wherein loading includes: 

modifying said target external metadata to describe said one or more 

database objects; and 
modifying said target database metadata to define a copy of said set of 
tablespaces as a set of tablespaces that are used to store said 
data for at least one of said one or more database objects. 

125. The computer-readable volatile or non-volatile storage device of Claim 124, 
wherein generation of a module includes analyzing the source database metadata for 

dependencies. 

126. The computer-readable volatile or non-volatile storage device of Claim 125, 
wherein analyzing the source database metadata for dependencies includes ensuring 

proper order of loading of the source database metadata into the target 
database. 

127. The computer-readable volatile or non- volatile storage device of Claim 124, 
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further comprising instructions which, when executed by one or more processors, 
causes the one or more processors to perform: 

storing said module in one or more files in a source file system. 



128. The computer-readable volatile or non-volatile storage device of Claim 127, 

further comprising instructions which, when executed by one or more processors, 
causes the one or more processors to perform: 

said target ETL application reading a specification containing information for 
how to move modules from said source file system to a target file 
system; 

wherein said information comprises a network protocol and the 
location of said one or more files; and 
said target ETL application accessing said one or more files in a source file 
system based on said information. 



129. The computer-readable volatile or non-volatile storage device of Claim 128, 
wherein the network protocol is one of FTP, HTTP, HTTPS, or rsync. 



130. The computer-readable volatile or non-volatile storage device of Claim 124, 

further comprising instructions which, when executed by one or more processors, 
causes the one or more processors to perform: 
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in response to a failure occurring during the loading of said database objects 
within said target database, rolling back all changes made during the 
loading of the database objects to the target database. 

131. The computer-readable volatile or non-volatile storage device of Claim 124, wherein 
said one or more database objects to be transported from a source database to a target 
database includes a database object that has metadata stored outside of the source 
database. 
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EVIDENCE APPENDIX 
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RELATED PROCEEDINGS APPENDIX 

None. 



OID 2003-177-01 



41 



